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Upgrading Nine Concord Avenue/Garden St 
Signals to MBTA’s NextGen TSP 
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1.0 Executive Summary 


The MBTA, in partnership with local traffic signal owner-operating agencies, 
operates a Transit Signal Priority (TSP) system to improve the on-time performance 
and operational efficiency of the transit system.’ The MBTA bus/light rail fleet are 
equipped with onboard communications and GPS location technology that provides 
location and status information. The signal systems are expected to obtain this 
information from MBTA’s existing Automated Vehicle Location (AVL) system and 
provide TSP.’ 


The Next Generation of Transit Signal Priority and Signal Performance Measures 
Technical Specification is intended to serve as guidance to local agencies when 
procuring traffic signal control hardware and software to meet current best in class 
functionality including the specialized needs of the MBTA. It will also address 
improving accuracy of ‘stop bar’ arrival predictions, which significantly impacts TSP 
effectiveness; enabling the collection of high-resolution data for each intersection, 
allowing for more robust evaluation of the TSP system as a whole; and providing a 
suite of technologies at varying levels of technological capabilities and cost. As a 
benefit for the local agency, the high-resolution signal data collected by the 
Advanced Transportation Controllers (ATC) can be processed into Signal 
Performance Measures (SPMs) and then be used to optimize signal operations 
without the need for time consuming and expensive traffic studies. 


1.1 MBTA TSP Operations 


TSP operates as follows: 


e The MBTA uses AVL to track bus locations on a continuous basis. MBTA makes 
this location information available in real-time through their publicly available 
API at www.mbta.com/developers. 

e The priority request generator (PRG) identifies a bus approaching a signalized 
intersection. 

e A priority request is created for each active in-service bus on the route and sent 
to the priority request server. 

e Once received, a call is placed into the controller to request priority. There are 
several priority treatments that can reduce the time it takes the bus to move 
through the intersection. The two most common are extended green or 
shortened red. The decision to grant priority along with the type of treatment 
and the logic to recover to normal operations is all determined by the rules 
within the ATC. 

e When the bus leaves the intersection, the priority request generator triggers the 
call to be dropped and the signal returns to normal operation. 


1 These specifications focus on buses, but also apply to Green Line trolleys, which are within the purview of TSP when traveling 
through mixed-traffic intersections. 


? These specifications do not apply to for example the signals connected to the City of Boston’s Traffic Management Center. 


The ATC collects and logs data including traffic volumes (from the intersection 
detectors), pedestrian pushbutton activity, signal phasing, TSP calls, and other 
controller functions every tenth of a second. This data is periodically sent to the 
local Agency and/or MBTA API for processing into T-SPMs. 
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Figure 1 Transit Signal Priority Operational Diagram 


The system components included in this specification includes: 


1. Controller: The traffic signal controller is the piece of equipment in the 
signal cabinet that translates input from detectors into the displays that are 
detected on the street. Signal timing parameters are programmed into the 
controller software to determine the allocation of green time and interpreting 
detector and display information. 


2. Priority Request Generator (PRG)/Priority Request Server (PRS): The 
PRG and PRS are functional entities that work together to provide the 
necessary services needed to request TSP. In the case of MBTA, the PRG 
would receive active in-service bus AVL data on a continuous and real-time 
basis directly via the MBTA API. The PRS receives these data and translates 
them into the actual detector cabinet and/or controller inputs assigned to 
that function based on controller configuration. The PRS may perform 
additional filtering and logic functions based on local agency policy that may 


determine if and when a request is made. The MBTA uses unconditional TSP 
for every intersection therefore additional logic is not anticipated. The local 
traffic signal controller then determines if and how to adjust timings to 
support a priority movement for the bus based on a pre-defined TSP timing 
configuration. The controller determines issues such as_ reconciling 
simultaneous requests from different buses for competing priorities or lock 
out times that limit how often priority may be requested within a given time 
period. 


The architecture and implementation details of the PRG/PRS may vary greatly 
depending on selected solution and agency equipment capabilities. Both a 
center-to-field (C2F) and center-to-center (C2C) architectural model are 
possible to implement TSP within the MBTA operational region. With C2F, the 
PRG may be either on-premise or cloud hosted. The PRG would communicate 
directly to a PRS in each field traffic signal controller cabinet thereby 
bypassing any central traffic signal management capability. In this scenario a 
PRS device in each cabinet would receive the information and place a priority 
call into the controller. This would most likely be the case in situations where 
the local traffic signal owner-operating agency does not have a central traffic 
signal management system with full-time communications to each traffic 
signal cabinet. With C2C, the MBTA server communicates the AVL messages 
directly to the traffic signal owner-operating agency centralized traffic 
management system. The centralized traffic management system would 
include the PRG functionality and would use the same communications path 
supported by other centralized traffic operations to also issue the TSP request 
to the traffic signal controller. The PRS function may reside centrally 
alongside the PRG or may be distributed to each traffic signal cabinet 
depending upon implementation details. 


. Communications and _ Reporting: The MBTA’s’ goal of — signal 
communications is twofold; to provide TSP for transit vehicles moving 
through a signalized intersection, and to retrieve the hi-resolution data from 
traffic signal controllers to analyze and understand operational performance. 


The MBTA has completed an effort to standardize transit detection setup so 
that this can be used with the ATSPM enumeration to produce Transit focused 
Signal Performance Measures (SPM). This data is typically stored in a circular 
buffer on each traffic signal controller. Each controller event is time stamped 
and stored in a first-in/first-out buffer that will begin to automatically 
overwrite the oldest events once the buffer is full. The number of recorded 
events over a given period is dependent upon the intersection complexity 
and traffic volumes. 


2.OIntroduction and Overview 


The Massachusetts Bay Transportation Authority (MBTA) is looking to upgrade 9 
traffic signals to MBTA’s next generation TSP specifications. The vendor will ensure 
that the following criteria are met: 


1. Traffic controller needs to have data recording based on NTCIP 1211 
standards as defined in the Indiana Traffic Signal Hi Resolution Data Logger 
Enumerations (where required, as defined in the project scope below). 
Technical Specifications are defined in Section 3.1 “Controller Specifications” 

2. Traffic controller needs to adhere to the MBTA’s data logging standards as 
defined in MBTA’s Virtual Bus Detector Methodology, Section 4.0. 

3. Traffic controller needs to adhere to the “Communications and Reporting” 
specifications as described in section 3.3 

4. Priority Request Generator needs to adhere to latest specifications as 
described in the Priority Request Generator/Priority Request Server (PRG/PRS) 
and “Communications and Reporting”, described in sections 3.2 and 3.3, 
respectively. 


2.1 Intersection Locations 
All intersections are in Cambridge, MA 


e Concord Avenue & Blanchard Road 
¢ Concord Avenue & Moulton Street 
e Concord Avenue & Alpine Street 

e Concord Avenue & Walden Street 
e Concord Avenue & Huron Avenue 
e Concord Avenue & Craigie Street 

e Garden Street & Concord Avenue 

e Garden Street & Mason Street 

e Garden Street & Appian Way 


* Return all unused TSP and signal equipment not needed for upgraded signal work 
to their respective municipalities. 


3.0 System Components 


The system components below provide for the performance standards required for a 
new or upgraded system to facilitate the continued MBTA TSP operation and 
collection and reporting of standard compliant hi-resolution traffic data that is 
required to calculate Signal Performance Measures to MBTA. It also provides the 
capability to improve ETA predictions over time. The vendor will ensure that the 
following criteria are met: 


3.1 Controllers 

To provide the data needed for T-SPMs a NEMA standard ATC Controller with hi- 
resolution data logger is required. The data logger collects signal controller status 
on a 1/10" of a second interval. The data is defined and formatted in accordance 
with the Indiana Traffic Signal Hi Resolution Data Logger Enumerations 3?(August 
2020 or latest version.) This document defines the enumerations, events, 
parameters, and descriptions of all hi-resolution data to be recorded on the traffic 
controller and forms the basis for calculating Signal Performance Measures. 


e TS2-2016 Traffic Controller Assemblies with NTCIP Requirements Version 
03.07 is the latest NEMA Traffic Signal Controller standard that provides a 
functional, mechanical, and electrical interface definition for the Field I/O 
connectors of the traffic controller. It provides cabinet level 
interchangeability but does not define nor support controller hardware or 
application software interchangeability. A controller from one vendor can be 
easily swapped with another vendor controller within the same NEMA TS2 
cabinet, but controller component hardware and application software remain 
proprietary to the vendor. The TS2 standard utilizes a Synchronous Data Link 
Control (SDLC) serial communication Field I/O bus to communicate with 
cabinet devices. 


¢ NTCIP 1202 v2 (Actuated Signal Controller object definition) with the 
Indiana _ Traffic Signal Hi-Resolution Data Logger Enumerations 
(defined in NTCIP 1202 v3) and allows for operational data to be retrieved 
from the controller. The following events are Mandatory [M], Strongly 
Recommended [SR], and Desired [D] to be in the high-resolution log. 


i. [M] Phase Begin Green 
ii. |[M] Phase Begin Yellow Clearance 
iii. |[M] Phase End Yellow Clearance 


iv. [M] Detector Check-in (for TSP virtual detectors, defined in the MBTA TSP 
detection guidance) 


Vv. [M] Detector Check-out (for TSP virtual detectors, defined in the MBTA TSP 
detection guidance) 


3 Li, Howell & Hainen, Alexander & Sturdevant, James & Talukder, Md Abu Sufian & Mathew, Jijo & Bullock, 
Darcy & Nelson, Daniel & Maas, Donald. (2019). Indiana Traffic Signal Hi Resolution Data Logger Enumerations. 
10.5703/1288284316998. 


vi. = [M] TSP Check-in 

vii. [M] TSP Check-out 

viii. [M] TSP Types (Early Return, Green Extension, etc.) 
ix. | [M] TSP denied reason 


x. [M] Priority Parameter (Time of Service Desired, Priority Class, Transparity 
Parameter, etc.) 


xi. [SR] Detector Check-in (other) 
xii. [SR] Detector Check-out (other) 
xiii. [SR] Phase Gap Out 
xiv. [SR] Phase Max Out 
xv. [SR] Phase Force Off 


xvi. [D] Other event listed in the Indiana Traffic Signal Hi Resolution Data 
Logger Enumerations 


e The NTCIP 1211 Object Definitions for Signal Control and Prioritization (SCP) 
standard defines the application layer data to be exchanged to support bus 
or rail transit signal priority (TSP). The NTCIP 1211 SCP Concept of Operations 
is comprised of two primary elements, the Priority Request Generator (PRG) 
and a Priority Request Server (PRS). A transit vehicle, which could be a light 
rail train, bus, or other transit vehicle, through its agent, the PRG, submits a 
request for priority to the PRS. These two elements can be thought of as a 
logical process that could be physically implemented in more than one way. 
The specific hardware implementation details are not defined here but left to 
the local agency and MBTA to determine. The standardization occurs at the 
interface of these processes and represents the objects developed by NTCIP 
1211. The two primary interfaces are (1) between PRG and PRS and (2) 
between PRS and the traffic signal controller coordinator, which implements 
special coordination operation. 


ATC 5201 v06.34 standard defines a minimum required functional 
capability of hardware and software for an on-street transportation controller 
computing platform. A key component of the standard is the Engine Board 
which contains all of the computational facilities. Standardized edge 
connectors define how this board mates with the receiving Host Module of 
the controller platform. While the Engine Board is completely specified, the 
Host Module and the rest of the controller platform may be of various shapes 
and sizes based on vendor preference. The intention is to allow portability of 
the Engine Board to accommodate upgrades with technology advances or 
cross vendor deployment. The standard defines minimum physical interfaces 
to ensure compatibility with all major transportation field cabinets. 


3.2 Priority Request Generator (PRG) / Priority Request Server 
(PRS) 
i. ©The PRG should be capable of ingesting AVL data, providing simple trip wire 
check-in/check-out detection based on virtual detector locations, and 
evaluating each received AVL record to determine the bus location relative to 


the TSP detector locations. 
The PRG needs to have a map of the agency intersections, intersection 
names and numbers, and accurate geospatial information about each 
intersection TSP detectors (check-in, and check-out) for all bus routes and 
approaches. 
o The TSP virtual detectors shall be programed based on the MBTA TSP 
detection guidance, “Virtual Bus Detector Methodology,” section 


3.3 Communications and Reporting 

The MBTA’s goal of signal communications is twofold; to provide TSP for transit 
vehicles moving through a signalized intersection, and to retrieve the hi-resolution 
data from traffic signal controllers to analyze and understand operational 
performance. 


i. Either modem to connect signal to cloud and receive priority and preemption 
requests, or central signal system with active link to signals and connected to 
the cloud. 

ii. | All communications need to be compliant with national standard (NTCIP) 

iii. © All communications to support this capability need to conform to Internet 
Protocol (IP) broadband standards. 

iv. For the TSP systems to operate properly, hardware must be capable of 
supporting continuous full-time IP communications. 

v. Depending upon the local agency architecture, the communications can 
either be dedicated to the TSP function or be combined with other signal 
management functions onto a single communication channel. 


To support TSP operation, the traffic signal owner-operating agency needs to have a 
centralized PRG process capable of connecting to the MBTA’s API. This connection 
enables reception of continuous and real-time bus location data. 


i. An Internet-based virtual private network (VPN) broadband connection 
(typically 1-15Mb/s) with MBTA is preferred. 

ii. A single PRG process and VPN-based API connection is preferred to manage 
this interface more efficiently. 

iii. TSP communications between the PRG/PRS and each local traffic signal 
controller requires minimal bandwidth (typically <1Mb/s). 

iv. Low latency performance is required for each connection to ensure timely 
reception and processing of TSP requests. 


To support hi-resolution data reporting, the traffic signal owner-operating agency 
needs a centralized file server capable of connecting to the MBTA API to report back 
hi-resolution data collected and stored on the traffic signal controller. 


i. Asingle Internet-based VPN API connection (typically 1-15Mb/s) is preferred. 

ii. This connection may be shared with the PRG. 

iii. © Communications between the central file server and each local traffic signal 
controller requires minimal bandwidth (typically <1Mb/s). 

iv. Either FTP or API can be used to report the data. Both need to account for the 
possibility of duplication due to the nature of the controller circular buffer. 
The vendor API need to be compatible with MBTA system to allow data 
reporting. The MBTA Customer Technology Department (CTD) team shall 
provide the specifications on the API details. 

v. To avoid conflict, it is recommended that only a single central system for 
each agency be responsible for collecting and storing the data from each 
controller and then making it available to all other users including the MBTA. 

vi. |The upload frequency of the data from each controller shall be an hour or at 
maximum upload frequency and storage capacity shall be sufficient for a 


Xi. 


Xii. 


year worth of data. 

Security. All data and access to data stored on the controller shall be 
password protected and secure. 

Data recording. See Section 4.0 Virtual Bus Detector Methodology on how 
transit location data is to be recorded within the controller data logger. 

Data Transfer. All Signal Controller Data shall be transmitted hourly to 
MBTA’s Amazon Web Services (AWS) S3 bucket “cloud storage”. If vendor 
utilizes Amazon AWS, MBTA will provide cross account access. If vendor does 
not utilize Amazon AWS, MBTA will provide the access key and secret key to 
storage. Any data written in a proprietary format must be decoded by the 
vendor to convert the data to a comma separated values file type (CSV). This 
decoding can either occur prior or after submitting the data to the MBTA’s 
“cloud storage” but it is the vendor’s responsibility that this data has been 
converted to the CSV regardless of where in the process this conversion 
occurs. 

Troubleshooting. If the data is not transmitting properly which could be due 
to a number of factors including but not limited to: internet or power outages 
at the traffic signal, data corruption issues, file transfer issues or software 
credentialing issues the vendor shall make a reasonable and timely effort to 
troubleshoot and resolve the issue within 3 business days. 

Years of Service and Renewing. It is expected that the vendor will provide 
signal data for 3 years from installation. If vendor is no longer doing business, 
vendor shall provide reasonable accommodation to transfer product and 
software to MBTA and/or municipality. 

Unless otherwise specified, all internet communication to/from the signal 
controller and its component parts shall be in operation for 15 years. 


4.0Virtual Bus Detector Methodology 


The purpose of this memorandum is to establish a regionally consistent 
way to define detectors to locate buses with respect to a signalized 
intersection for high-resolution signal controller data. The vendor will ensure 
that the following criteria are met: 


Background 


To provide Transit Signal Priority (TSP) at a signalized intersection, an 
arriving bus is first detected with an upstream detector and a request is 
made to the signal controller to prioritize the bus movement through the 
signal. To measure the effectiveness of TSP, high-resolution signal controller 
data is utilized to track changes to signal phasing and timing, bus arrivals, 
and delays. 


Within the MBTA service area, each municipality installs, operates, and 
maintains its signal controllers in its jurisdiction, using various signal 
controller manufacturers, operating infrastructure, and communication 
infrastructure. However, each TSP vendor must detect an MBTA transit 
vehicle via our publicly available API. * 


MBTA is in the process of developing a dashboard to capture transit- 
specific performance metrics at TSP-enabled intersections utilizing high- 
resolution signal controller data. To enable this, MBTA is developing 
specifications to standardize TSP functionality, detector placement, 
reporting of metrics, and high-resolution data formats. 

This memo addresses the detector placements of typical intersection 
layouts to demonstrate how to locate a bus arrival upstream of an approach 
and track the bus location as it traverses the intersection. The bus-specific 
detector calls are logged into the high-resolution data files, which are then 
processed to generate TSP-specific performance metrics. 


Detector Lengths 


Bus detectors should be sized to capture the necessary number of GPS 
pings from a bus. The recommended detector length can be calculated 
based on the formula below: 


L=v x(n+1)xfx1.467 

Where: 

L= recommended detector length (ft), rounded up to the nearest 50 
v= average bus travel speed (mph) 


n= minimum number of pings needed to geolocate the bus and the direction 
of travel 


f= bus ping frequency (sec) 
For example, if a bus travels at an average speed of 20 mph, pings every 6 
seconds and the geolocator system needs two pings to locate the buses, then the 


* http://www.mbta.com/developers 


recommended detector length is 20 * (2+1) * 6 *1.467 ~ 550 ft. 
Detector Placement 


For each intersection approach, when possible, place 3 virtual ‘geofence’ 
detectors at each approach one % mile upstream, one % mile upstream and one L 
(recommended length) feet to the stop bar. Additionally, place one virtual 
‘geofence’ detector as a check-out on the departure approach. When this is not 
feasible due to upstream signalized intersections, adjust accordingly by placing the 
furthest upstream detector immediately downstream of the next upstream signal. 
All upstream detector boundaries shall start at the aforementioned locations 
enabling the bus to trigger the detector. For the detector at % mile upstream, the 
detector shall begin at % mile upstream and shall be the calculated length 
downstream. 


Detector Event Parameter Values 


The purpose of the event parameter values is to identify the bus approach 
and movement with respect to the signalized intersection. Each virtual ‘geofence’ 
detector is assigned a unique parameter value of event codes 82 detector-on and 
81 detector-off as defined in the Indiana Traffic Signal Hi Resolution Data Logger 
Enumerations® that can be mapped to the intersection. Given that each intersection 
is unique and could have multiple configurations, a consistent way to number 
parameters of detector events is necessary. 


Using the approach that is closest to the cardinal north direction, detector 
parameters can be numbered starting from 50 for the upstream check-in detector 
and sequentially numbering them until the check-out detector. The numbering 
continues on the next approach in the clockwise direction and sequentially 
numbering them from the upstream check-in to the check-out. 


For example, if an intersection has four legs, and the approach that is closest 
to cardinal north has four detectors: a check-in, an update, a stop-bar and a check- 
out detector, they would be numbered 48, 49, 50, and 51 respectively. 


Detector configurations for typical intersection layouts 


Figures 1,2 and 3 show the configuration of a typical 4-legged, 3-legged 
and 5-legged intersection respectively. 
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Figure 2: Detector Configuration - 4-legged intersection 


As mentioned previously, the approach that is closest to cardinal north 
(southbound approach) has three upstream detectors and a downstream check-out 
detector, they shall be numbered 49 through 52. Next, working clockwise through 
the approaches, the westbound approach shall be numbered 53 through 56, the 
northbound approach shall be numbered 57 through 60 and the eastbound 
approach shall be numbered 61 through 64. 
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Figure 4-2: Detector Configuration - 3-legged intersection 
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Figure 5-3: Detector Configuration - 3-legged intersection 
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Figure 6-4: Detector Configuration - 3-legged intersection 


A three-legged intersection shall be numbered like a 4-legged intersection 
but skipping the numbers for the absent leg. Take Figure 2-4 as example, the 
approach that is closest to cardinal north (southbound approach) has three 
upstream detectors, and a downstream check-out detector, they shall be numbered 
49 through 52. Next, working clockwise through the approaches, the westbound 
approach check-in detectors shall be numbered 53 through 55 but 56 for check-out 
detector shall be skipped since there’s no receiving lane on the west side. The 
northbound approach shall be numbered 57 through 60. The eastbound approach 
check in detectors shall be skipped since there is no eastbound approach and the 
check-out detector shall be numbered 64. 
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Figure 7: Detector Configuration - 5-legged intersection 


For a five-legged intersection, the approach that is closest to cardinal north 
has three upstream detectors and shall be numbered 45 through 48. Other 
approaches shall be numbered going clockwise as shown in the above figure. 


NOTE: For intersections that are more than four-legged but only have bus 
service on four or less legs, numbering shall be the same as the four or three- 
legged intersections. This way for bus service in the same cardinal direction along a 
corridor all detector zones will be numbered identically as the bus passes from 
intersection to intersection along a corridor. 


5.0 Glossary of Abbreviations 


ATC: Advanced Transportation Controllers 

ATSPM or ATSPMs: Automated Traffic Signal Performance Metrics 
AVL: Automated Vehicle Location 

C2C: Center to Center 

C2F: Center to Field 

ETA: Estimated Time of Arrival 

GPS: Global Positioning System 

GTFS: General Transit Feed Specification 

IFB: Invitations For Bids 

ITS: Intelligent Transportation Systems 

M60: Model of signal controller currently owned by Yunex. 
MBTA: Massachusetts Bay Transportation Authority 

NEMA: National Electrical Manufacturers Association 

NTCIP: National Transportation Communications for ITS Protocol 
PRG: Priority Request Generator 

PRS: Priority Request Server 

TSP: Transit Signal Priority 


